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E agle is an intergrated set of tools, architectures, 
processes, patterns, and reusable components that 
Andersen Consulting brings to its clients to enable 
the design and development of mission critical business 
systems. One of the frameworks explored in the area of 
tailorability was the externalization of business-object 
behavior, which makes conven- 


compilation, but is useful in its own right as an intermedi¬ 
ate representation between source code and compiled 
code. The tree representation is convenient for dealing 
with syntactic issues. This representation can be trans¬ 
formed via decompilation into a string representation, 
with which most users prefer to interact. One representa¬ 
tion can be transformed into the 


tional black-box bu si ness-object 

behavior available for tailoring by ThetOOl guarantees 

behavior is represented as rule- that thesourcecode it produces 
bases, which are specified in wi 11 always COITipi leand, 

smaiitaik This paper describes a a f- run time, will n&/er generate 
tool that can be used to create and u 

edit the rules of the rule-bases. The t/iedoesNotllnderstand: message. 
tool guarantees that the source 
code it produces will always com¬ 
pile and, at run time, will never generate the rule-base derives 
doesNotUnderstand: message. The tool is a context-sensitive Warehouse business 


other as is convenient. Valid syntax 
and valid message-selectors are 
achieved by constraining the user to 
choose from valid manipulations of 
the ProgramNode tree. Valid message 
arguments are achieved by having 
the user choose from manipula¬ 
tions that satisfy type require¬ 
ments. Here is an example of a rule- 
base consisting of two rules. The 
the attribute isReceiving for a 
object. 


editor that makes use of typing information and handles 
a wide range of expressions. 

The basic technique is to transform a source string via 
manipulation of its abstract syntax tree. The abstract syn¬ 
tax parse tree, or more accurately ProgramNode tree in Visual 
Works, is produced as an intermediate step during code 


Rulel premise: [:aWarehouse | aWarehouse 
isTakingl nventory] 

Rulelaction: [:aWarehouse | aWarehouse 
isReceiving: false] 

Rule2 premise: [:aWarehouse | aWarehouse 
isTakingl nventory not] 



Figure 1. Starts with a generic seed-block of [subject | nil]. 


Rule2action: [:aWarehouse | aWarehouse 
isReceiving: (aWarehouse isOpen and:[aWarehouse 
isAvai lableStorage]) ] 

As the example shows, a rule contains a single-argument 
block; the argument being the instance of the business 
object. The nature of Eagle rules is that they tend to be 
short and simple. The tool in turn was designed to per¬ 
form well for shallow-nested blocks and a small number 
of assignments and temps. 

PPD VisualWorks was the development environment; 
concepts mayor may not be applicable to other Smalltalk 
environments. 

The standard input to the tool is a string specifying a 
si ngle argument block and the class name of the busi ness 
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Figure 2. DEMO 2. 
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Figure 3. DEMO 3. 
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object. The output is a similar string. Let's create the 
action block of Rule2, starting with a generic seed-block 
of [subject | nil] as shown in Figure 1. 

The view in the upper right is the ProgramNode tree. The 
user has the ability to select a node either by clicking on it 
in the tree view, or by clicking appropriately on code in 
the NodeSelection text view (shown). For example, to select 
a MessageNode in the text view, the user clicks on its selec¬ 
tor. We click on nil, which is a LiteralNode. 

We proceed to replace the nil statement with the argu¬ 
ment of the block. We have replacement options avai lable 
from four lists: Morph, MorphConstruct, MetaMorph, and 
MetaMorphConstruct. These options (collectively referred to 
as morphs) produce valid replacement nodes for the cur- 
rent-selection. Morph proper and MorphConstruct produce 
rep I acement n odes of the same class as that of the cu rrent 
selection; MetaMorph and MetaMorphConstruct produce 
those of a different class. The construct suffix means that 
the replacement node, instead of being a fixed prototype, 
is rather constructed from the current selection. For 
example, construct sel -> sel isNil (sel denoting current 
selection) means: replace the current selection with a 
MessageNode of selector isNil, and use the current selection 
as the receiver. 

Let's metamorph. We select subject in theMetaMorph list. 
This replaces theLiteralNode with aVariableNode and, we get 
Figure 2. 

The Morph list presents the option of using global 
Transcript; it is possible to have other globals as well. We 
select MetaMorphConstruct sel -> sel isNil. This replaces the 
VariableNode with a MessageNode, whose receiver is the 
VariableNode, and then we get Figure 3. 

We have expanded the MorphConstruct list and see 
choices for different selectors. Each of these choices 
shows the return type (depicted by the up-arrow), as well 
as the requi red types for the arguments (if any). (The ver¬ 
tical bar appearing in a type specification is read as or.) 
We pick sel ->sel rcvr isReceiving:. This replaces the current 
MessageNode with another MessageNode of the same receiv¬ 
er, but different selector, that of isReceiving:. 

Let's proceed by showing remaining steps with descrip¬ 
tive text, where bold emphasis indicates current selection. 


4) [:subject | subject isReceiving: nil] 

5) [subject j subject isReceiving: nil] 

6) [:subject j subject isReceiving: subject] 

At this point, as shown in Figure 4, the label at the top of 
thetreeview has turned red and now reads: Type Mismatch 
instead of Type Match. The current selection appears 
(inverted) red in thetreeview, and the Accept button at the 
lower right is disabled. The red color for the node indi¬ 
cates that for that particular node, there is a type mis¬ 
match. The type status in the lower left shows that the 
required-type is Undefined Object | (kindOf: Boolean) >, but 
the actual type is <Warehouse>. Warehouse is neither an 
Undefined Object nor a kindOf: Boolean, so the required type 
is therefore not satisfied. Unless all nodes have their 
required type satisfied, thetool will not permit the code to 
be accepted. 

Whereas each allowed manipulation of the ProgramNode 
tree will result in correct syntax, it will not necessariIy sat¬ 
isfy required type for all ProgramNodes. As far as the tool is 
concerned, an unsatisfied required type is the sole cause 
for the generation of thedoesNotUnderstand: message. The 
tool guarantees prevention of thedoesNotUnderstand: mes¬ 
sage, by requiring that all required types are satisfied. The 
user is alerted to type mismatches, and it is the user's 
responsibility to satisfy them. Type mismatch usually 
occurs with message arguments. 

We continue to morph, aware that the type mismatch 
was due to an intermediate morph step. 

7) [subject | subject isReceiving: subject isNil] 

8) [subject j subject isReceiving: subject isOpen] 

9) [subject j subject isReceiving: subject isOpen isNil] 

10) [:subject | subject isReceiving: (subject isOpen 

and: [nil])] 

11) [:subject | subject isReceiving: (subject isOpen and: 

[nil])] 

12) [[subject | subject isReceiving: (subject isOpen and: 

[subject])] (At step 12 there is another type mismatch, 

again with the argument of isReceiving: .) 

13) [[subject | subject isReceiving: (subject isOpen and: 

[subject isNil])] 

14) [[subject | subject isReceiving: (subject isOpen and: 
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Figure 4. DEMO 4. 
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Figure 5. DEMO 5. 


[subject isAvailableStorage])] 

We're almost done creating the action block. We now 
select theVariableNode block argument subject and rename 
it to aWarehouse by editing its name in the edit box; this 
renames all references in the scope of the variable. 


parenthesized and formatted in theNodeSelection view (as 
we have seen). Also in this view, the user is able to walk 
up the tree by shift clicking. 

Assignment to a block is not supported, nor is sending 
it #value. Cascaded expressions are currently not support¬ 
ed. 

NODE WRAPPERS 

The ProgramNode class hierarchy (somewhat simplified) is 
shown in Figure 6. Instance variables are shown with soft 
type (gleaned from class comments). Note that a 
BlockNode containsaSequenceNode, which in turn contains 
temporaries and statements. 

ProgramNode (sourcePosition <lnterval>) 

ParameterNode (variable <VariableNode>) 
StatementNode 
ReturnNode 
ValueNode 

AssignmentNode (variable <VariableNode>, 
value <kindOf: ValueNode>) 

CascadeNode 

LeafNode 

BlockNode (arguments Collection of: 
ParameterNode>, body <SequenceNode>) 

LiteralNode (value <kindOf: Object>) 
VariableNode (name <String>) 
SequenceNode (temporaries Collection of: 
ParameterNode>, statements Collection of: (kindOf: 
StatementNode) >) 

SimpleMessageNode (receiver <kindOf: 
ValueNode>, selector <Symbol>, arguments Collection of: 
(kindOf: ValueNode)>) 

MessageNode 

The ProgramNode class-hierarchy (somewhat simplified). 


15) [:subject | subject isReceiving: (subject isOpen 
and: [subject isAvailableStorage])] 

16) [;aWarehouse | aWarehouse isReceiving: 
(aWarehouse isOpen and: [aWarehouse isAvailableStorage])] 

That's it, and ittookatotal of 15 mouse clicks (not includ¬ 
ing list expansions) and one name edit. 

Now let's say we wanted to add another statement to 
the action block. We start by selecting the Sequence 
Statements collection. A collection editor is installed in the 
lower right, as shown in Figure 5. We select the single state¬ 
ment, and then click on the Add Before button, and get: 

[:aWarehouse | 

nil. 

aWarehouse isReceiving: (aWarehouse isOpen and: 
[aWarehouse isAvailableStorage]) ] 

The added nil statement can then be built out via morph¬ 
ing. The collection editor can also modify a collection of 
temporary-variables 

The tool has unlimited undo/redo capability, as well 
as the ability to alternate between NodeSelection and 
Freestyle (i.e., regular) text views. Text is automatically 


A wrapper class hierarchy that parallels that of the 
ProgramNodes was created. The wrapper classes refer 
to the ProgramNode classes and extend them, but the 
ProgramNode classes themselves are not modified, thus 
keeping the compiler framework intact (Adapter pat¬ 
tern 1 ). The wrapper hierarchy (somewhat simplified) 
is shown in Figure 7. (AbstractParserTraverser and 
MessageWrapperBlockArgument Evaluator are technically not 
wrappers, but are referred to as such.) 

AbstractParserTraverser (parent, children) 

MessageWrapperBlockArgumentEvaluator 
AbstractParserWrapper (value) 

AbstractProgramNodeWrapper (type, 
requiredType) 

ParameterNodeWrapper 

AbstractStatementNodeWrapper 

ReturnNodeWrapper 

AbstractValueNodeWrapper 

AssignmentNodeWrapper 

AbstractLeafNodeWrapper 

LiteralNodeWrapper 
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BlockNodeWrapper 

VariableNodeWrapper 

SequenceNodeWrapper 

MessageNodeWrapper 

MessageNodeWithArgumentsWrapper 
Ord ered Co 11 ect i o n Wra p per 
ParentOfUserRoot 

The wrapper hierarchy (somewhat simplified). 

Added state allows a ProgramNode to know its parent, as 
well as keep track of its required and current type. 
OrderedCollectionWrapper wraps collections pointed to by 
ProgramNodes; this includes SequenceNode statements and 
MessageNode arguments. M ani pulation is defined as 
either wrapper replacement or addition/dele¬ 
tion of an OrderedCollection Wrapper child. 

Not having the option of modifying the ProgramNode 
classes can be tricky. It was necessary for example, to 
deep-copy a ProgramNode, an ability which it lacks. The 
technique is to regenerate it by compiling its decompiled 
string. 

THE USER-ROOT 

The user-root parent hierarchy is designated as follows: 
nil 

BlockNodeWrapper 

SequenceNodeWrapper 

ParentOfUserRoot 

The ParentOfUserRoot is an OrderedCol lecti on Wrapper on 
sequence statements and is constrained to always have 
one statement- the user root. Wrapper replacement is 
forbidden for any wrappers above the user root. I ndeed, 
the user is aware of the user-root tree only. The user-root 
must have a parent because the user root needs to be 
replaceable, and this requires a parent wrapper. As a 
kind of AbstractStatementNodeWrapper, the user root has 
flexibility in being replaceable with wrappers of other 
classes. 

CONSTRUCTS 

Constructs are obtained from the soft-typing information 
of ProgramNode instance variables (as shown in Figure 6.). 
For example, take a MessageNode, which is a statement. 
This node can be replaced with any of the subclasses of 
StatementNode such as ValueNode. Since the receiver of a 
MessageNode is itself a ValueNode, it follows that it ispermis- 
sibleto replace thisMessageNode with its receiver, as shown 
in Figure8. 

Replacing a statement MessageNode with its receiver. 
Construct Return message receiver (123 isNil -* 123). 

The fol lowi ng constructs are supported: 

• Return message receiver (123 isNil -► 123) 

• Be message receiver (123 -> 123 isNil) 

• Change messageselectorand argumentsonly (123 +456—>123* nil) 

• Change message selector only (123 +456 -► 123 * 456) 
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Figure 6. Branch. 
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Figure 7. Loop. 


• Return block's first and only statement ([123] -> 123) 

• Enclose statement in block (123 ->■ [123]) 

• Return assignment value (tl : = 123 ->• 123) 

• Be assignment value (123 ->■ tl : = 123) 
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• Remove up-arrowT> (^123 -► 123) 

• Add up-arrow (123 -► *123) 


MANIPULATION VALIDATION 

Each potential manipulation must be validated to be 
made available to the user. A manipulation is invalid if it 
hasn't been implemented for example, like the replace¬ 
ment of a message receiver. A manipulation is invalid if it 
is syntactically incorrect. For example, the definition of a 
temporary variable may not be deleted if the variable is 
currently referenced. 

We also check the ramifications for message receivers 
if the type of a temporary variable were to change. For a 
message-receiver whose type is determined by a tempo¬ 
rary, we ensure that the receiver's required type is satis¬ 
fied. For example, tl isEmpty, where the receiver's 
required-type is <kindOf: Collection>. If the type of tl were 
to change from <ByteString> to <Smalllnteger>, for example, 
the check would fail, because <kindOf: Collection would 
not be satisfied with <Smalll nteger>. This check is accom¬ 
plished by simulating the manipulation on a parallel test 
tree to preview the results. 


CORRECT SOURCE POSITION 

Wrapper source-position information enables the user to 
select the wrapper by clicking on it in a text view. A pris¬ 
tine ProgramNode tree will have correct source-position 
information stored in its nodes. Once the tree is manipu¬ 
lated, however, this information is no longer guaranteed 
to be in synch with the decompiled string. Thetechnique 
isto create a parallel ProgramNode tree after every manipu¬ 
lation, by compiling the decompiled string of the modi¬ 
fied wrapper tree. A wrapper seeks its correct source posi¬ 
tion from its parallel node counterpart. 

Instead of directly replacing a node in thetree, why not 
do so indirectly by replacing the corresponding string 
component in the overall string? For a BlockNode, for 
example, replace thestring'[nil]' in the correct spot in the 
overall string. Then, from this overall string create a fresh 
wrapper tree that would then have the correct source 
position. This approach, however, also has a drawback; 
The state information in the pre-manipulation wrapper 
tree must always be transferred to the post-manipulation 
wrapper tree. 

In the next article, we plan to conclude by looking at 
typing, traversal of the wrapper tree, treatment of blocks, 
and creation of the wrapper-tree. H 
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